1. Field of the Invention
Example embodiments of the present invention are related generally to a method of configuring an adaptive module for an offline charging system.
2. Description of the Related Art
Communication devices (e.g., wireless communication devices, wired communication devices, etc.) may be provisioned services which are associated with a certain fee or charge. The service provisioning is monitored and reported to a billing domain for the service provider in order to charge or bill the requesting communication device. The charging may be “online” in the sense that the billing is performed at the same time as the service being rendered, which may also be referred to as “real-time” charging. Alternatively, the charging may be “offline” in the sense that the billing is separate from the service provisioning. For example, offline charging may include storing charging information and periodically uploading the stored charging information, such as at a monthly billing invoice. Online charging, which may be reported over an Ro interface to a network (e.g., a different interface may be used in 1 G and 2 G networks], may directly affect the service provisioning in real-time (e.g., if a cell phone user exceeds his/her time limit, the call may be ended, etc.). In contrast, offline charging does not necessarily affect the service provisioning in “real-time”.
3 GPP Release 6 standards define an offline charging system to provide charging services. FIG. 1 illustrates a block diagram of a conventional offline charging architecture in accordance with the 3 GPP Release 6 standards.
Referring to FIG. 1, the offline charging architecture includes an offline charging network 100, which is connected to a billing domain (BD) 140 via an interface Bx. The offline charging network 100 includes a charging trigger function (CTF) 110, a charging data function (CDF) 120 and a charging gateway function (CGF) 130. The billing domain 140 may correspond to a billing system and/or a billing mediation device.
While not illustrated in FIG. 1, it is understood that the CTF 110 is an integrated component (e.g., a software component) within each “network element” (NE) of the offline charging network 100. As used herein, a network element is any network physical entity or function entity within the offline charging network 100 (e.g., Call Session Control Function (CSCF), Application Server (AS), Multimedia Resource Control Function (MRFC), Gateway GPRS Support Node (GGSN), etc.) that may provide charging data to enable the CDF 120 to generate a charging data record (CDR), as will be described in greater detail below. For example, the network element may correspond to a serving call session control function (S-CSCF), a proxy-CSCF (P-CSCF), an interrogating-CSCF (ICSCF), a breakout gateway control function (BGCF), a media gateway control function (MGCF), an application server (AS), etc.
The CTF 110 generates charging events by monitoring network resource usage. The CTF 110 receives information from its network element. This information includes, but is not limited to, charging information relating to the services provided by the network element within which the CTF 110 is located. The CTF 110 is the focal point for collecting the charging information pertaining to charging events and charging sessions related to the network element. The CTF 110 assembles this charging information into charging sessions and charging events, and sends the charging sessions and charging events to the CDF 120. Charging sessions and charging events are well-known in the art. Generally, the CTF 110 includes an accounting metrics collection function and an accounting data forwarding function.
The CDF 120 receives the charging sessions and charging events from the CTF 110 via an Rf interface. The Rf interface is a “diameter reference point”, and functions as an interface between one or more network elements within the offline charging network 100 and the CDF 120. Typically, the network elements within the offline charging network 100 send Accounting Record (ACR) messages (e.g., start, interim, stop, event, etc.) to the CDF 120 for offline charging. The CDF 120 responds to the messages received from a given network element with an acknowledgement (e.g., an accounting answer (ACA) response). The CDF 120 uses the information contained in the ACR messages (e.g., relating to charging sessions and charging events) to construct and/or modify Charging Data Records (CDRs). The CDF 120 then transfers the CDRs to at least one CGF 130 via an interface Ga. The interface Ga is a physical interface between the CDF 120 and the CGF 130. Generally, the Ga interface is used to transfer CDRs generated or modified in the CDF 120 to the CGF 130.
The CGF 130 acts as a gateway between the offline charging network 100 and the BD 140. The CGF 130 uses a Bx interface to transfer CDRs to the BD 140. Generally, CDR files are transferred from the CGF 130 within the offline charging network 100 to the BD 140 on the Bx interface in accordance with well-known protocols, such as File Transfer Protocol (FTP), secure FTP (SFTP), etc. Upon receiving the CDR files, at the BD 140, from the CGF 130 on the Bx interface, the BD 140 processes the CDRs to generate subscriber bills.
In session based charging, the CDF 120 opens a CDR when an initial charging event (i.e., an event specifying the start of a charging session) is received. The CDF 120 adds information to an opened CDR in response to receiving interim charging events, which may occur during a charging session. The CDF 120 may then close a CDR for a variety of reasons. The closing of the CDR may be based on the configuration on the CDF 120. For example, the CDF 120 may close a CDR based on one or more of the following: a CDR time limit; a CDR volume limit; a limit of change on charging conditions; an end of user session (i.e., reception of the final charging event describing the charging session termination); and implementation limits (e.g. memory size).
If the CDF 120 closes a CDR, but the charging session remains active, a subsequent CDR is opened. Hence multiple “partial CDRs” may be needed to completely describe the charging session for charging purposes. As such, the opening and closure of CDRs may occur asynchronously to the reception of the charging events.
The following two formats of partial CDRs are generally described in the 3 GPP Release 6 standards. The first format is referred to as a Fully Qualified Partial CDR (FQPC) and is a partial CDR that contains a complete set of CDR Fields. The second format is referred to as a Reduced Partial CDR (RPC) and is a reduced format partial CDR that contains the Mandatory fields (M) as well as changes occurring in any other field relative to the previous partial CDR.
The 3 GPP Release 6 standard defines a high-level functionality for the CDF 120 and the CGF 130. The 3 GPP Release 6 standard also defines a high-level functionality for an “integrated” CDF/CGF (e.g., see FIG. 3) which performs both CDF and CGF functions, but cannot perform exclusive CDF or exclusive CGF functions. In order to implement and maintain the CDF 120, the CGF 130 and/or the integrated CDF/CGF, a design team typically develops an application module specific to the particular function to be implemented. Accordingly, if the design team is requested to provide application modules to a dedicated CDF functionality, a dedicated CGF functionality and a dedicated integrated CDF/CGF functionality, three separate application modules need to be developed and maintained. Hardware and software development and maintenance within such application modules is typically very expensive.